Hadoopソースコードリーディング 第17回に参加してきました

Hadoopソースコードリーディング 第17回に参加してきました

Clock Icon2014.09.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Hadoopソースコードリーディング 第17回に参加してきました。今回のテーマは7月にApacheのTop-Level Project入りしたばかりのApache Tezについてでした。なお、全体的にApache Sparkと比較する形での説明が多かったので、Sparkについてご存じない方は前回のHadoopソースコードリーディング 第16回に参加してきましたをご参照下さい。

NTTデータ濱野さんの冒頭の挨拶

  • 今日は別のイベントも多いためいつもの半分ぐらいの参加者だが、その分Deepにやれれば
  • いつもの会場だと途中からピザとお酒だが、今回の会場は飲食禁止なので最後までシラフで
  • Tezに関する勉強会は初回なのにいきなりタイトルがInternalsとかになってますねw

Tez Internals (@oza_x86 さん)

@oza_x86 さんからはTez Internalsということで、Sparkと対比しながらのTezの概要の説明、WordCountを例にAPIの解説がありました。

  • 本日の資料はApache Tez Source code reading
  • TezとSparkの比較
    • 参考資料Apache Tez: Accelerating Hadoop Query Processing
    • 皆さんSparkは知ってますよね?昨日のやつ参加してますよねw
    • TezはYARN前提
    • ソフトウェアスタックとしてはSparkと衝突する
    • Sparkとの比較はバージョンによって性能が大きく変わるので一概にいえない
    • Tezはディスクベースに最適化している。一方Sparkはインメモリから始まっているので、そこが大きな違い
    • Tezはレイヤーが1つ低い。上位Hive、Pigなどのアプリケーションが追従しない場合は自分たちにコミッターがいるのでパッチをあてて対応させている。Sparkは単体Spark DSLが存在して利用できる
    • 一番の違いはRDDの有無
    • Dynamic reconfiguration APIsでReduceの数を自動で決めてくれる。DryadOptimusみたいなもの。統計情報からDAGを書き換えるようなもの。Tezはそこまではやっていないが
    • Q. Apache Flinkとの違いは? -> A. こちらはコンパイラでがんばる感じ
  • ソースはHadoopよりも読みやすい
  • 動作させるにはHDFSにjarを置いて、ちょっと設定を変えるだけ。MapReduceはエミュレータの実装があり、Hiveは処理系をTezに変える
  • 処理モデル
    • Vertex
    • Tezはタスク間のデータの受け渡しをユーザーが定義できる
      • One-To-One
      • Broadcast
      • Scatter-Gather
  • API
    • Vertex毎にVertexManagerがいる。例えばOne-To-Oneに対応するshuffleしない実装のVertexManagerが存在する
  • WordCount
    • https://github.com/apache/tez/blob/release-0.5.0/tez-examples/src/main/java/org/apache/tez/examples/WordCount.java
    • 263行あって、Spark好きが見たら。。。
    • TokenProcessor
      • MapReduceにおけるWordCountのMapperに相当する
      • kvReaderはHadoopのソースを読んだことがある人はわかるがMapReduce内部のソースでも同じように書かれている。Tezはより低レイヤーなのでこれをAPIとして露出している
    • SumProcessor
      • MapReduceにおけるWordCountのReducerに相当する
      • Q. 識別子(vertexName?)の単位は? → A. Vertex単位?
      • APIを見ていて思うが、一般のユーザーが使うものではないのでは。あくまでHiveやPig経由で使うことを想定しており、これはそういうものを作る人向けのサンプルなのでは
  • ShuffleVertexManager#TEZ_SHUFFLE_VERTEX_MANAGER_ENABLE_AUTO_PARALLELをtrueにすることでDynamic reconfigurationが有効になる。

アプリケーションエンジニアから見たTez (@marblejenka さん)

@marblejenka さんからはTezの周辺、Sparkとの比較、そして改めてWordCountとの比較についての説明がありました。なお、詳細はスライドをご覧ください。以下は主に口頭のみでスライドに書かれていない点になります。

  • @oza_x86 さんとネタが丸かぶり。。
  • Twitterなどでよくつぶやいている「この豚野郎!」はPig使って欲しいという意味でつぶやいていた
  • Tezは本格的に触っているわけではない。仕事でも今のところ使っていない
  • Tezが出てきた背景はProposalにもあるようにHiveやPigにMapReduceは向いていないから
  • Tezの系譜としてはNephele/PACTsHyracksに影響を受けているらしい
  • Dryadは論文を4回読んで4回挫折した。何がすごいか分からなかったが、難しいということは分かった。実装が公開されているので、何がすごいのか教えてください
  • FlinkはNephele/PACTsの実装。RoadmapにTez上で動作させるとあるので、将来的にTez上でSparkっぽいAPIを使いながらScalaで書けるようになるはず
  • TezとSparkの比較
    • Tezに動的最適化があったり、SparkにのみRDDがある点。あと、Tezは既存のMapReduce実装を使いまわせる
    • Sparkは機械学習で、それ以外はTezがいいのでは
  • Tezを作っている人は元MSとか元Yahoo!なので期待できますね!
  • アプリケーションの作り方
    • ProcessorがMapper/Reducer的なもの。Processorを組み合わせてDAGを作る
    • 忘れているかもしれないので改めてWordCountの説明
    • テストは書きやすくなさそう
    • デプロイはjarを置くだけなのでとても簡単。複数バージョンもインストール可能なのがいい
    • Swimlanesmで処理結果を後で可視化してチューニングできるのが嬉しい
    • DAGがTopologyになったら本気出そうと思っていたらDAGのままとなった ← 0.5でAPIがstableとなったので名前はもう変わらないのでは?(@oza_x86 さん)
  • Processorを生で書くのは時期尚早感があるのでまずはPigやHive経由で
  • MapReduceはなくならないのでは。耐障害性の部分が異なるので。MapReduceであればその直前のReduceの結果は保証される(と言うといろいろ刺されますが。。)
  • QA
    • Q. HDP以外でもTezは使える? -> A. 使える
    • Q. Hive on Tez
      • Costベースのオプティマイザは実装されてなくてOracleから来た人がOptimusとセットで実装している
      • KVReaderがハングするというバグがある ← もともとMRの頃からあったものでは。修正中のはず

おまけ

Tezの動的最適化がよく分からなかったので個人的に@oza_x86 さんに質問しました。かなりイメージがわくようになりました。ありがとうございました!

  • Q. Tezが最適化出来る範囲はどこなのか? -> A. Reducerの数。なお、Scatter-Gatherの場合のみ。One-To-Oneであれば1:1になるし、Broadcastの場合も全体に配るだけなので
  • Q. どうやってReducerの数を変えるのか? -> A. 出力したデータを一時的に貯めておいて、そこで探索するとか?まだ分かっていないので調べる予定
  • Q. Reducerの数を最適化したい理由は? -> A.Hadoopクラスタの有効活用。単一のジョブでリソースを専有できるならReduce slotを使いきればよいが、複数のジョブが実行される場合は全体の利用状況を考えてReducerの数を決める必要がある。
  • Q. ということは、クラスタの情報をInputとして渡すことになるのか? -> A. 将来的にはそうなるのでは。まずはクラスタ全体は考えずに単純な方法でReducerの数を決定する方法が実装され、その後クラスタ全体のリソース状況を考慮するものが実装されるのでは

感想など

TezはDAGらしいという程度の知識しかなかったので、とても勉強させてもらいました。ありがとうございます!おかげさまで雰囲気は理解できた気がします。あと、参加していてSparkは必須の知識になっているんだなーと思いました。

合わせて読みたい

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.